How the NWUI works
The NetWorker Web User Interface (NWUI) uses the following technologies: HTML5, Apache Tomcat, Spring Framework, Angular Framework, and Representational State Transfer (REST) Application Programming Interface (API). The NWUI application can be installed on Linux or Windows operating systems. It can be installed either directly on the NetWorker server or on a host which is not the NetWorker server.
There are four important components:
These components can be on the same host or on separate hosts.
- Web front-end: This is the presentation layer written in HTML5 and Angular Framework which presents NetWorker operations to the user through a web browser. The web-browser is connected to the UI backend processes.
- UI Backend: The backend application is written in Spring Framework. It uses java and Apache Tomcat. Communication between the front-end and backend and between the backend and the NetWorker server is done using internal REST API calls. The NWUI process uses either the existing Apache Tomcat instance on the NetWorker Server or installs its own Apache Tomcat instance if installed remotely from the NetWorker server.
- NetWorker Server: The NetWorker Server REST framework is responsible for receiving the REST API calls from the UI backend and connecting them to the NetWorker Server's core components. The NetWorker Server RabbitMQ message bus is also used for interaction with nsrjobd.
- AuthC: The authc component of NetWorker is used for all authentication needs. The requesting process contacts AuthC to verify credentials; upon verification, AuthC issues a time, based, signed, and encrypted token. NetWorker components use this token to verify the user and authorize or not a requested operation. This is usually on the NetWorker server, but can be installed on a separate host.
Most of the communication is using REST API
which allows interaction with resources identified by Uniform Resource Identifier (URI) addresses. It uses HTTP verbs (HEAD, GET, PUT, POST, DELETE) to interact with the Uniform Resource Identifiers (URI) in a stateless way. These REST API calls are internal to NetWorker and NWUI operations. They are not to be confused with the NetWorker REST API interface that provides programmatic access to NetWorker for programming custom-built operations which is described in the NetWorker REST API Developer Guide.
Troubleshooting
Defining the Issue
ISSUE DETAILS
In order to generate a complete problem description, consider the following questions:
- What operation is being attempted which is not working?
- Does this operation work when initiated from outside NWUI (for example: From the NetWorker Management Console (NMC))?
- Is the issue consistent or intermittent?
- If intermittent, is there a known trigger?
- Did this work better before, and if so are there any known changes applied before and after the issue appeared?
- When did the issue first occur (and what changed since issue appeared)?
- Does the issue happen only at times of heavy load on the backup environment?
- What is the scope of the issue (all recovery operations/some recovery operations, some tabs not working while others are not impacted)?
- What has been tried so far to fix and what conclusions have been drawn from this?
ENVIRONMENT DETAILS
- What is the NetWorker server version and operating system platform?
- Is NWUI installed on the NetWorker server or a separate host?
- What is the NWUI version if installed on a host separate from the NetWorker server?
- What Java package is installed on the NWUI server; is NetWorker Runtime Environment (NRE) installed or Oracle Java Runtime Environment (JRE).
Authentication
Authentication uses AuthC in the same way as the NetWorker Management Console and the
nsrlogin command. For authentication issues, start by testing the authentication on the NetWorker server itself in order to separate whether the authentication issue is related to the NWUI or not. If you are using an external authentication method such as AD or LDAP, it is advised to first test authentication with local NetWorker accounts to see if the issue only impacts the external authentication method.
A typical command used to test whether the authentication process is working as expected on the NetWorker Server is:
authc_mgmt -u [user name] -p [password] -e find-all-users.
Or:
Local NetWorker account:
nsrlogin -u ACCOUNT -p PASSWORD
nsrlogout
External (AD/LDAP) account:
nsrlogin -t TENANT -d DOMAIN -u USERNAME -p PASSWORD
nsrlogout
Installation Issues
Browser-Side Issues
If multiple browsers are installed, test the observed issue in different browsers to see if the issue is specific to one browser.
In the browser, use the right-click and 'inspect' in order to see the REST API calls which are being made from the browser as well as log statements and network connection information.
- Right-click anywhere in the browser window and select 'inspect'
- A new window opens up with several tabs. The 'Console' and 'Network' tabs are likely to be the most useful.
- Using these tabs, we can see the exact REST API calls which are being made to the NetWorker server.
- In the network tab, we can also see the request method and the REST API response from the NetWorker server. In this way, we can trace exactly what is being requested of the NetWorker server and exactly how the NetWorker server is responding to this request.
UI backend issues
The important UI backend logs are:
catalina.log - Tomcat server logging and application deployment logging.
nwui.log - NWUI application server logging.
restapi.log - NetWorker REST API logging. NWUI communicates with the NetWorker server using NetWorker REST API.
daemon.raw - NetWorker server logging.
The location of these log files depends on the operating system being used as well as whether the installation of the NWUI is local to the NetWorker server or remote it. If the NWUI is on the NetWorker server itself, then it shares the same tomcat instance with NetWorker.
If you are providing a .raw log file to support, it is advised to render the log file on the system from which it originates. This ensures that the timestamps are rendered in the local time of the server:
NetWorker: How to use nsr_render_log
Log Files
Linux:
The processes which run for the UI backend are: /opt/nwui/bin/nwuictld and jsvc.exec You can check if they are running with the ps command:
The logs are here:
Local to NetWorker server:
- /opt/nwui/logs
- /nsr/authc/logs/
- /nsr/logs/restapi/restapi.log
- /nsr/logs/daemon.raw
Remote:
- /opt/nwui/logs
- /nsr/nwui/logs
Windows
The windows NWUI backend process which must be running is called nwuictld.exe:
You can manage this from services.msc:
The logs are here:
Local to NetWorker server:
- C:\Program Files\EMC NetWorker\nwui\logs
- C:\Program Files\EMC NetWorker\nsr\authc-server\logs
- C:\Program Files\EMC NetWorker\nsr\restapi\restapi.log
- C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw
Remote:
- C:\Program Files\EMC NetWorker\nwui\logs
- %LOCALAPPDATA%\Temp\NetWorker_Management_Web_UI_Server_[TIMESTAMP].log
- %LOCALAPPDATA%\Temp\NetWorker_Management_Web_UI_Server_[TIMESTAMP]_0_MCUI.log
NetWorker Server
Run the nsrget tool on the NetWorker server to collect the relevant logs:
NetWorker: How to Use the NSRGet NetWorker Data Collection Tool
The most relevant logs depend on the operation being attempted from the NWUI. For more information about NetWorker logs, see:
NetWorker: Log Files and Locations
Debugging
In order to debug the REST API communication, change the debug level in the logback.xml file on the NetWorker server:
Windows: C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\webapps\nwrestapi\WEB-INF\classes
Linux: /nsr/authc/webapps/nwrestapi/WEB-INF/classes
Uncomment the lines dealing with API call logging. This causes the logging level to be set to 'trace' for the REST API requests and responses.